Skip to content

chore: Minimal supported editor correction #3836

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
michalChrobot wants to merge 8 commits into
base: develop-2.0.0
Choose a base branch
from
Open

chore: Minimal supported editor correction #3836

michalChrobot wants to merge 8 commits into from
+21 −19

Conversation

@michalChrobot
Copy link
Member

@michalChrobot michalChrobot commented Jan 7, 2026 •
edited
Loading

Purpose of this PR

While looking at https://discussions.unity.com/t/problem-with-netcode-1-0-2/1701859/2 I was wondering why package manager was not suggesting updates to latest NGO version and while this is probably related to the fact that user was working un unsupported tech stream of Unity editor and this is not NGO fault I realized one issue that we have

In our package.json we use "unity": "6000.0" and in contrast to Netcode for Entities implementation we are not using "unityRelease": "23f1". The difference is as follows:

1. Behavior with unityRelease specified
With the configuration "unity": "6000.0" and "unityRelease": "23f1", the Package Manager interprets this as a strict minimum requirement.

Minimum Version: The package explicitly declares that it requires Unity 6000.0.23f1 or higher.
Behavior: If a user tries to install this package on an Editor version lower than this (e.g., 6000.0.0b10), the Package Manager will flag it. Specifically, if installed on an older version, the Package Manager window will display an info icon in the details header indicating that the package version is not recommended for that Unity version.

2. Behavior without unityRelease specified
If we don't have "unityRelease": "0f1" and leave only "unity": "6000.0", the restriction becomes broader.

Minimum Version: The Package Manager considers the package compatible with the entire 6000.0 cycle (and newer).
Behavior: It effectively sets the "floor" to the beginning of that major/minor version cycle. It will not complain if the user is on a beta or alpha of 6000.0, provided the major.minor matches or exceeds the requirement.

Our issue is that in our CI we specified minimum editor to 6000.0 and while using unity-downloader-cli -u {{editor}} command the tool fetches the latest available release for that version stream (e.g., 6000.0.36f1), not the initial release (e.g., 6000.0.0f1).
It is not fair or safe to claim support for 6000.0 (which implies 6000.0.0f1 and up, also alpha and beta versions) while only testing on the latest patch (e.g., 6000.0.36f1).

The risk is that we develop and test only on 6000.0.36f1 and we might inadvertently use an API or a bug fix that was introduced in 6000.0.40f1.
As a consequence the user running 6000.0.0f1 will be able to install our package (because our package.json says 6000.0 is fine), but the package will crash or fail because the API it relies on doesn't exist in their editor version.

To resolve this I specified "unityRelease": "0f1" and set minimal test editor to that version (6000.0.0f1). This means that

  1. We specifcally offer support to all supported 6000.0 editors while having a safe minimal requirement
  2. We perform our validation on PRs with latest (trunk) and proper minimal editor (6000.0.0f1) wile running all other tests daily/weekly (6000.0.0f1, 6000.0, 6000.3 etc)
  3. If something will start failing in relation to editor API then we can "simply" increase this minimal patch version as needed
  4. We will avoid unexpected failures on our PRs due to API changes in latest 6000.0 editor while we will still be able to catch those via daily/weekly tests. So our tests on PRs should be a bit more stable

Jira ticket

https://jira.unity3d.com/browse/MTT-14264

Changelog

  • Changed: Minimal supported editor was set to first 6000.0 LTS version 6000.0.23f1 to clarify that we do not guarantee that the package will work on alpha or beta versions of 6000.0

Documentation

N/A

Testing & QA (How your changes can be verified during release Playtest)

I will run our CI triggers to see if everything is executed as expected

Backports

Will do

@michalChrobot michalChrobot self-assigned this Jan 7, 2026
@michalChrobot michalChrobot marked this pull request as ready for review January 8, 2026 14:17
@michalChrobot michalChrobot changed the title Minimal supported editor correction chore: Minimal supported editor correction Jan 15, 2026
@michalChrobot
Copy link
Member Author

michalChrobot commented Jan 15, 2026

/review

@u-pr-agent
Copy link

u-pr-agent bot commented Jan 15, 2026

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🎫 Ticket compliance analysis 🔶

MTT-14264 - Partially compliant

Compliant requirements:

  • Add unityRelease to package.json to enforce a strict minimum supported Unity editor patch version (so minimum is not “any 6000.0 alpha/beta”).
  • Update CI to run PR validation against the true minimal supported editor (e.g., 6000.0.0f1) instead of a moving “latest patch in 6000.0 stream”.
  • Keep PR validation stable by testing both minimal supported and a “latest functional” editor, while still covering trunk separately.
  • Clarify supported editor expectations to users (avoid implying support for alpha/beta 6000.0).

Non-compliant requirements:

  • Make it easy to raise the minimal patch requirement in the future if API/bugfix dependencies require it.

Requires further human verification:

  • Make it easy to raise the minimal patch requirement in the future if API/bugfix dependencies require it.
⏱️ Estimated effort to review: 2 🔵🔵⚪⚪⚪

Small configuration-only change across CI config and package metadata, with minimal surface area but requires validating downstream CI behavior.
🏅 Score: 88

Changes are aligned with the ticket goal and are low-risk, but version pinning in CI and the downgraded test framework dependency should be validated for availability/compatibility.
🧪 No relevant tests
🔒 No security concerns identified
⚡ Recommended focus areas for review

Version Pinning

CI now pins UNITY_VERSION to 6000.0.0f1 and 6000.3; confirm unity-downloader-cli (and Yamato images/caches) can reliably resolve these values and that 6000.3 is interpreted consistently (not drifting to an unexpected patch/pre-release).

 
    "job_name": "Build Sample for Windows with minimal supported editor (6000.0.0f1), burst ON, IL2CPP",
    "variables": [
        { "key": "BURST_ON_OFF", "value": "on" },
        { "key": "PLATFORM_WIN64_MAC_ANDROID", "value": "win64" },
        { "key": "SCRIPTING_BACKEND_IL2CPP_MONO", "value": "il2cpp" },
        { "key": "UNITY_VERSION", "value": "6000.0.0f1" } # Minimal supported editor
    ]
},
{
    "job_name": "Build Sample for Windows with latest functional editor (6000.3), burst ON, IL2CPP",
    "variables": [
        { "key": "BURST_ON_OFF", "value": "on" },
        { "key": "PLATFORM_WIN64_MAC_ANDROID", "value": "win64" },
        { "key": "SCRIPTING_BACKEND_IL2CPP_MONO", "value": "il2cpp" },
        { "key": "UNITY_VERSION", "value": "6000.3" } # Editor that most our users will use (not alpha). Sometimes when testing on trunk we have weird editor issues not caused by us so the preference will be to test on latest editor that our users will use.
    ]
Dependency Downgrade

com.unity.test-framework is changed from 1.6.0 to 1.4.6; ensure this downgrade is intentional and does not break existing tests or required editor/tooling compatibility.

 
"com.unity.test-framework": "1.4.6",
"com.unity.test-framework.performance": "3.2.0",
Compatibility Semantics

With unity set to 6000.0 and unityRelease set to 0f1, verify this matches the intended “minimal supported editor” messaging and does not unintentionally exclude supported beta/alpha workflows beyond what the team wants.

 
"unity": "6000.0",
"unityRelease": "0f1",
"dependencies": {
  • Update review

🤖 Helpful? Please react with 👍/👎 | Questions❓Please reach out in Slack #ask-u-pr-agent

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@NoelStephensUnity NoelStephensUnity Awaiting requested review from NoelStephensUnity NoelStephensUnity is a code owner

@EmandM EmandM Awaiting requested review from EmandM EmandM is a code owner

At least 1 approving review is required to merge this pull request.

Assignees

@michalChrobot michalChrobot

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@michalChrobot